Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000130_owner-urn-ietf _Thu Oct 31 04:07:27 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA10480 for urn-ietf-out; Thu, 31 Oct 1996 04:07:27 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA10475 for <[e-mail]>; Thu, 31 Oct 1996 04:07:25 -0500
Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21124  (mail destined for [e-mail]); Thu, 31 Oct 96 04:07:23 -0500
Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id EAA11716; Thu, 31 Oct 1996 04:07:23 -0500
Message-Id: <[e-mail]>
From: [e-mail] (Leslie Daigle)
Date: Thu, 31 Oct 1996 04:07:22 -0500
In-Reply-To: Daniel LaLiberte's message as of Oct 30, 15:21
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Daniel LaLiberte <[e-mail]>,
        "Karen R. Sollins" <[e-mail]>
Subject: Re: Names and Locations (was [URN] some comments)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: [e-mail] (Leslie Daigle)
Errors-To: [e-mail]

Dan, forgive me for using your message as an opportunity to write down
some basic definitions to make sure we ae all on the same page here...

[Dan LaLiberte wrote:]

> I agree.  But "a URN syntax" seems to imply that there must be just
> one syntax for all URNs.  Did you mean that?

>From the perspective of the work this group is doing, we neeed _a_ URN
syntax.  Because we are attempting to accommodate a broad range of name
spaces, the syntax is designed to be flexible -- ony specifying those things
that must be in order to be able to write software that handles URNs.
(E.g., acceptable character sets, how to handle escaping characters where
necessary, etc).    The URN syntax does not, however, have anything to say
about what structure a particular namespace wishes to use in the NSS
(i.e., namespace specific (opaque) string).

I think Karen's point was that this syntax should be defined
from the perspective of what we're trying to do with URNs, and not from the
technological  limitations or strengths of a particular implementation of
the architecture.

> We should state that name space identifiers and URI schemes are in the
> same name space.  Call them all the same thing: "URI Schemes".

Perhaps a convenient (and maybe even necessary) approach, but it should be
kept in mind that a URN name space is not the same thing as a URL protocol
(see below) -- so this starts to be a collection of apples and oranges.

> In general, each scheme, whether for a URL or URN, should be
> associated with some resolution protocol.

I'm not sure I'm clear on what you're getting at here, and even if we do agree,
I think there is some potential for the above to be a bit misleading.

The point of the indirection in the URN naming is to abstract the (final)
resolution protocol so that no name space is specifically associated with, say,
HTTP, or Whois++.  THe idea is that any URN can be resolved using different
protocols  -- at one time, or at different stages in its lifetime -- and this
is a separate process from determining the URN identifier string.

However, there is a general mechanism for handling URNs to the extent of
extracting Naming Authority, etc etc etc, which is standard across the URNs
we define here.

What _is_ associated with each name space is the particular means of extracting
the necessary namespace ID to look up the naming authority (i.e., perhaps from
the NSS, perhaps just based on the namespace, etc).  So, CID URNs might
have a mapping that describes how to pull a DNS name out of the string;
LesliesNamespace might have a mapping based on the phase of the moon.  All
LesliesNamespace URNs will require the use of this mapping in order to find
the Naming Authority, which will lead to a server speaking any of seaveral
possible protocols for the final resolution.

> You made the curious statement that URNs identify resources while URLs
> identify locations.  I'm not sure whether that was a slip, but to my
> mind, a URL *IS* a location that identifies a resource.  Now you also

URLs identify a particular location for a resource.  Mechanisms for migrating
that resource without changing the URL are based on aliasing techniques that
are external to the URL. It is therefore usually a problem when a particular
resource is moved to another location.

URNs identify a resource, independently of its location.  The indirection
mechanisms permit that a single resource may be in several locations at
once, or may migrate, without changing the URN.  This is handled within the
URN support framework, and is therefore consistent across URNs.  The idea
is that, in general, it should not be a problem if a resource is moved.

So, the URN identifies the resource; a URL identifies a location which is an
instance of a resource, nd these are qualitatively  different things (yes, I
am feeling brave this morning!).

Leslie.

--

----------------------------------------------------------------------------

  "The light at the end of the tunnel             Leslie Daigle
     is often the blindingly obvious..."          Vice President, Research
                                                  Bunyip Information Systems
                      -- ThinkingCat              [phone]
                                                  [e-mail]
----------------------------------------------------------------------------